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Abstract 


The  science  of  Command  and  Control  (C2)  of  military  forces  moves  increasingly  towards 
digital  systems.  As  such,  not  only  are  humans  consuming  this  information  but  also  so  are 
more  automated  systems.  The  need  to  use  simulations  to  interact  with  Command, 
Control,  Communications,  Computers,  Intelligence,  Surveillance  and  Reconnaissance 
(C4ISR)  systems  is  becoming  more  acute.  The  interaction  is  becoming  less  interpersonal 
and  focused  more  on  data.  Most  critical  of  all  the  C2  information  are  the  commander’s 
intent,  orders  and  directives,  but  these  don’t  currently  flow  as  data.  They  are  typically 
transmitted  as  “free  text”  elements  within  messages  or  as  stand-alone  files.  This  is 
acceptable  for  interpersonal  communication  but  it  is  inadequate  for  use  with  simulations, 
or  for  the  future  forces  that  have  robotic  components.  Commanders  demand  to  train  as 
they  fight.  This  means  using  their  C4ISR  devices  to  control  simulations  in  addition  to 
live  forces.  We  need  to  fix  the  “free  text”  problem.  Battle  Management  Language  (BML) 
is  a  means  to  provide  a  completely  unambiguous  C2  specification  for  live  forces, 
simulations  and  robotic  forces. 

Introduction 

In  May  of  2000  the  Department  of  the  Army  formally  chartered  the  Simulation  to  C4I 
(SIMCI)  Overarching  Integrated  Product  Team  (OIPT).  Its  mission  is  to  provide 
recommendations  on  Army  level  policy  to  the  Army  Modelling  and  Simulation  Executive 
Council  (AMSEC)  for  improving  interoperability  between  the  Models  and  Simulations 
(M&S)  and  Command,  Control,  Communications,  Computers,  and  Intelligence  (C4I) 
domains.  The  SIMCI  OIPT’s  specific  objectives  are  to: 

•  Achieve  seamless  interoperability  between  M&S  and  C4I  systems. 

•  Attain  alignment  of  M&S  and  C4I  standards,  architectures,  and  common  C4I 
components. 

•  Identify  requirements  for  simulations  and  C4I  to  support  interoperability. 


Among  the  SIMCI  OIPT’s  primary  projects  is  the  development  of  a  Battle  Management 
Language  (BML)  that  will  enable  direct  communications  between  standard  Army  Battle 
Command  System  (ABCS)  components  and  supporting  M&S  applications.  This  paper 
will  describe  the  background  and  concept  for  BML,  discuss  its  required  capabilities  and 
its  anticipated  contributions  to  the  SIMCI  Objectives,  the  Army’s  transformation  and  the 
Objective  Force.  BML  is  absolutely  essential  to  achieve  the  desired  state  of  Simulations 
to  C4I  interoperability,  and  can  contribute  significantly  to  the  Army  Battle  Command 
System  in  its  own  right. 

Background 

During  the  past  several  decades  the  use  of  models  and  simulations  has  increased 
exponentially  in  military  affairs.  Once  primarily  used  in  the  research  and  development 
community  and  concept  development  and  analysis  agencies,  these  tools  now  reach  across 
the  breadth  and  depth  of  military  organizations  and  functional  areas.  Of  the  domains, 
Training,  Exercise  and  Military  Operations  (TEMO)  is  the  most  interactive  with  C4I 
systems.  From  the  1980’s  to  the  present  the  use  of  simulations  to  support  training  has 
expanded  dramatically.  Simulations  such  as  Corps  Battle  Simulation  (CBS), 
Brigade/Battalion  Battle  Simulation  (BBS),  JANUS,  Close  Combat  Tactical  Trainer 
(CATT),  and  Modular  Semi- Automated  Forces  (ModSAF)  have  significantly  improved 
both  the  quantity  and  quality  of  training  opportunities.  This  is  particularly  true  at  the 
brigade,  division  and  corps  level,  where  the  primary  focus  of  training  is  on  the  command 
and  staff  processes.  In  the  past,  maneuver  space,  number  of  units,  and  logistic  resources 
made  it  impractical  and  unaffordable  to  conduct  effective,  realistic  command  and  staff 
training  at  the  division  and  corps  level.  Now,  using  these  supporting  simulations,  the 
highest  echelons  can  conduct  realistic  training  in  a  more  frequent  and  cost  effective 
manner.  The  major  drawback  of  using  computer- simulated  training  such  as  CBS, 
however,  is  the  need  for  large  contingents  of  support  personnel  to  act  as  workstation 
controllers.  The  controllers  provide  the  interface  between  the  training  unit  and  the 
simulation.  The  control  group  is  often  as  large,  or  larger  than,  the  training  audience. 
While  this  enables  training  opportunities  at  the  corps  and  division  echelons,  it  is  very 
expensive  in  terms  of  labor  costs  and  lacks  the  degree  of  fidelity  of  actual  combat 
operations. 

Concurrent  with  the  increased  use  of  modeling  and  simulation  in  support  of  training  has 
been  the  growth  and  development  of  automated  Command  and  Control  (C2)  systems 
particularly  at  lower  echelons  of  tactical  forces.  The  first  attempt  to  automate  fire  control 
was  the  Field  Artillery  Digital  Automated  Computer  (FAD AC).  It  was  fielded  in  1959. 
At  the  same  time,  a  requirement  for  the  Tactical  Fire  Direction  System  (TACFIRE)  was 
emerging.  TACFIRE  arrived  at  the  Field  Artillery  Board  in  1972  for  operational  testing 
and  was  fielded  to  the  1st  Cavalry  Division  Artillery  in  1978.  [2]  The  same  materiel 
requirement  for  TACFIRE  also  envisioned  development  of  automated  systems  in  other 
areas  of  Combat,  Combat  Support  and  Combat  Service  Support  operations.  The  program 
was  called  Army  Tactical  Data  Systems  (ARTADS).  While  the  initial  concept  sought 
interoperability  among  the  ARTADS  component  systems,  the  efforts  became 
“stovepiped”  as  additional  applications  were  developed  outside  the  original  unifying 


architecture.  They  had  very  specific  battlefield  functional  area  problems  that  they  were 
being  built  to  solve  and  interoperability  with  other  systems  was  not  a  primary  concern. 
Each  system  had  its  own  hardware,  operating  systems,  databases  and  software.  As  we 
moved  through  the  1980s  and  into  the  1990s  it  became  clear  that  there  was  a  need  for 
these  systems  not  only  to  communicate  with  each  other,  but  to  also  share  common 
information.  Efforts  were  initiated  to  fix  the  interoperability  of  these  systems  with  the 
Common  Hardware/Common  Software  Program  in  the  1980’s.  At  the  end  of  the  last 
decade  development  began  on  the  Joint  Common  Data  Base  (JCDB)  [7],  a  shared,  single 
repository  of  data  common  to  more  than  one  system.  The  result  is  today’s  Army  Battle 
Command  System  (ABCS).  The  ABCS  hosts  a  common  picture  of  the  battlefield  by 
integrating  information  horizontally  and  vertically,  i.e.  within  an  echelon  of  command 
and  from  higher  to  lower  echelons,  respectively.  ABCS  consists  of  the  following 
subsystems  and  is  depicted  in  Figure  1.  [13]: 

•  Global  Command  and  Control 
System  -  Army  (GCCS-A) 

•  Force  XXI  Battle  Command  Brigade 
and  Below  (FBCB2) 

•  Maneuver  Control  System  (MCS) 

•  All  Source  Analysis  System  (ASAS) 

•  Advanced  Field  Artillery  Tactical 
Data  System  (AFATDS) 

•  Forward  Area  Air  Defense 
Command  and  Control  (FA AD  C2), 


•  Digital  Topographical  Support 
System  (DTSS) 

•  Air/Missile  Defense  Planning  and 
Control  System  (AMDPCS), 

•  Combat  Service  Support  Control 
System  (CSSCS), 

•  Army  Airborne  Command  and 
Control  System  (A2C2S) 

•  Integrated  Meteorological  System 
(IMETS) 
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Figure  1.  Army  Battle  Command  System 


During  the  1990’s  the  Army  refocused  its  vision  from  the  cold  war  to  the  tenets  of  Joint 
Vision  XXI  and  Army  Vision  XXI.  The  tenets  include  Dominant  Maneuver,  Precision 
Engagement,  Focused  Logistics  and  Full  Dimensional  Protection.  Critical  to  achieving 
these  capabilities  is  the  concept  of  using  information  superiority  to  provide  vastly 
increased  C2  capabilities.  “The  evolving  doctrine  keys  on  information-age  technology. 
Digitization  of  the  force  will  give  our  soldiers  unprecedented  tools  to  conduct  battle  in  a 
manner  never  before  seen.  The  power  of  the  microprocessor  is  empowering  the  Army  to 
move  faster  and  more  effectively  -to  compress  time-  and  achieve  an  overwhelming 
competitive  advantage  in  the  information  age.”  [10]  The  Army  developed  new 
organizations,  doctrine,  tactics,  techniques  and  procedures.  These  were  tested  in  a  series 
of  experiments  focused  on  the  “digitized”  force.  The  experiments  provided  linked, 
automated  C2  systems  at  each  echelon  of  the  participating  units  from  the  platoon  through 
Corp  level. 

As  the  echelon  of  the  participating  units  increased  it  became  less  practical  to  execute  the 
experiments  with  a  full  compliment  of  live  friendly  and  opposing  forces.  A  greater  level 
of  modeling  and  simulation  support  was  used  to  accomplish  these  exercises. 
Additionally,  it  became  apparent  that  developing  a  suitable  level  of  proficiency  in  the 
participating  units  required  a  focused  training  regimen  with  sufficient  “battlefield 
loading”  of  the  interactive  information  systems. 

The  Impetus  for  a  Universal  Battle  Management  Language 

As  stated,  a  major  drawback  of  using  computer-simulated  training,  such  as  CBS,  is  the 
need  for  large  contingents  of  controllers  at  workstations  providing  the  interface  between 
the  training  unit  and  the  simulation.  One  of  the  key  issues  in  using  M&S  as  a  primary 
training  adjunct  to  advanced  C4I  systems,  and  directly  linked  to  the  workstation 
controller  topic,  is  the  lack  of  an  effective  means  of  sharing  information  and  directives 
among  the  simulations  and  the  C4I  systems.  A  method  of  enabling  the  C4I  systems  to 
both  exchange  information  directly  with  the  simulation  and  also  provide  for  the  direct 
control  of  and  feedback  from  the  simulated  subordinates  will  significantly  reduce 
workstation  controller  requirements  and  enhance  the  realism  of  the  training. 

The  Army  is  making  significant  progress  in  sharing  information  through  the  development 
of  the  JCDB.  However,  relatively  few  advances  have  been  made  on  controlling  the 
simulation  directly  from  the  C4I  systems.  This  is  due  largely  to  the  reliance  on 
unstructured,  ambiguous  “free  text”  within  the  operational  C2  messages.  “Free  text” 
existing  in  USMTF,  JVMF,  and  other  message  formats  exists  for  the  benefit  of  the 
human.  The  highly  trained,  professional  soldier  has  little  problem  dealing  with  this  “free 
text.”  Current  automated  systems  that  deal  with  “free  text”  handle  it  as  a  single  data  field 
and  pass  the  ccharacter  string>  on.  Understanding  the  content  of  the  ccharacter  string> 
does  not  exist  within  the  current  system,  nor  will  computers  be  able  to  parse  natural 
language  for  some  time  to  come.  Therefore,  to  resolve  both  of  these  issues,  the  concept 
of  a  BML  was  developed.  Taking  the  widest  possible  interpretation,  we  offer  the 
following  definition: 


BML  is  the  unambiguous  language  used  to  command  and  control  forces  and 
equipment  conducting  military  operations  and  to  provide  for  situational  awareness 
and  a  shared,  common  operational  picture. 

Along  with  this  definition,  we  add  four  principles  that  guide  BML  development: 

1.  BML  must  be  unambiguous; 

2.  BML  must  not  constrain  the  full  expression  of  a  commander’s  intent; 

3.  BML  must  use  the  existing  C4I  data  representations  when  possible;  and 

4.  BML  must  allow  all  elements  to  communicate  information  pertaining  to 
themselves,  their  mission  and  their  environment  in  order  to  create  situational 
awareness  and  a  shared,  common  operational  picture. 

Additionally,  in  constructing  BML  we  need  to  consider  its  flexibility  versus  its 
efficiency.  Efficient  BML  takes  the  form  of  interactions  that  are  highly  structured,  such 
as  communications  between  pilots  and  air  traffic  controllers  or  between  artillery 
observers  and  fire  direction  center.  The  efficiency  accommodates  the  tension  of 
dangerous,  stressful  situations  and  the  potential  for  degraded  communications  media. 
Flexible  BML,  on  the  other  hand,  approaches  the  concept  of  “free  text”  where  the  users 
communicate  in  natural  language.  At  the  extreme,  this  may  include  vocal  inflection  and 
body  language.  Since  our  objective  is  to  demonstrate  a  BML  for  use  with  current 
technology,  we  will  focus  more  on  the  efficient  end  of  the  BML  spectrum.  Objectively, 
BML  must  interpret  “free  text,”  even  to  the  degree  that  Arthur  C.  Clarke’s  “HAL9000,” 
in  the  movie  “2001  A  Space  Odyssey”  could  “sense”  human  intent  as  well  as  spoken 
language. 

As  emerging  and  future  simulations  develop,  we  face  three  options  in  meeting  the  BML 
requirement.  First,  we  can  create  BMFs  that  are  specific  to  each  simulation.  Second,  we 
can  develop  a  standard  simulation  BMF  and  add  interpreters  between  it  and  the  C4I 
systems.  Finally,  we  can  develop  a  BMF  that  is  standard  for  both  the  simulation  and  C4I 
domains.  To  support  the  “train  as  we  fight” 
maxim,  we  choose  to  develop  a  BMF  that 
will  be  standard  for  both  domains. 


Additionally,  it  is  vitally  important  that 
BMF  contain  no  user  noticeable  distinction 
between  live  or  simulated  forces  ensuring 
that  commanders  and  staff  can  train  as  they 
fight.  They  will  use  the  same  BMF  whether 
they  are  dealing  with  live  subordinates,  a 
simulation,  or  a  Future  Combat  System 
(FCS)  robotic  element,  (Figure  2).  For  a 
detailed  discussion  of  the  principles  of  this 
universal  BMF,  and  its  predecessors,  see  [3] 

The  Concept  and  Structures  of  BML 


To  achieve  acceptance  and  also  have  utility 


Figure  2:  BMF  Scope 


for  its  primary  ABCS  users,  BML  needs  to  have  a  familiar,  intuitive  “look  and  feel.”  The 
"common  look  and  feel”  is  manifest  in  the  “operational  battle  management  language,” 
used  by  military  professionals  to  interact  with  live  forces.  Doctrinal  manuals  such  as  FM 
101-5-1  (future  FM  1-02)  define  the  vocabulary.  The  associated  grammar  is  defined  by 
other  doctrinal  manuals  and  from  years  of  use.  It  is  tailored  to  interpersonal 
communications.  Doctrine  provides  the  base  line  for  common  understanding  amongst  all 
users.  Operational  BML,  however,  lacks  clearly  delineated  rules  governing  its  use 
(semantics  and  syntax)  and  is  riddled  with  ambiguity.  It  works  because  soldiers  have 
grown  up  with  it  from  the  moment  they  enter  the  service.  They  learn  its  idiosyncrasies 
along  with  the  idiosyncrasies  of  the  individuals  who  use  it.  When  a  term  is  used,  it  has 
context  based  on  the  operation,  unit  type  and  echelon,  and  individual  characteristics  of 
the  sender.  Likewise,  when  a  sender  selects  a  term  to  use  he  does  so  with  an 
understanding  of  these  same  factors  of  the  intended  audience.  Any  confusion  is  resolved 
through  give  and  take  between  sender  and  receiver.  Mentoring  and  coaching  is  a  part  of 
the  process  of  learning  the  “informal”  BML.  While  ease  of  use  is  this  operational 
language’s  main  strength,  its  main  weakness  relates  to  automated  systems,  specifically, 
lack  of  structure.  As  such,  it  is  incapable  of  supporting  the  full  range  of  automation  that 
the  Army  is  implementing.  It  demands  further  development  and  modification. 

The  Simulation  Community  has  developed  several  languages  that  are  similar  to  the  BML 
we  are  developing.  The  highly  structured  EAGLE  BML  [9],  the  Command  and  Control 
Simulation  Interface  Language  (CCSIL)  [11],  and  the  Army  Modeling  and  Simulation 
Office  (AMSO)  BML-1  standard  [1]  were  developed  to  support  simulations.  While 
successful  in  their  application,  they  are  not  operational  user  friendly  and  do  not  adhere  to 
C4I  data  representations.  The  Defense  Modeling  and  Simulation  Office  has  sponsored 
development  of  a  Conceptual  Model  of  the  Mission  Space  [6]  which  defines  terms 
traceable  to  service  doctrine,  but  was  also  not  oriented  towards  C4I  Data  Representations. 

The  primary  vehicle  in  the  Army  for  adding  the  required  structure  to  BML  is  the  JCDB. 
The  JCDB  focuses  on  two  macro  areas:  first  are  the  physical  elements  of  the  battlefield, 
which  are  referred  to  as  objects;  and  second,  the  data  for  employment  (actions)  of  the 
elements  (objects)  of  the  battlefield. 

The  physical  elements  of  the  battlefield  fall  into  five  general  categories:  Person, 
Organization,  Materiel,  Leature,  and  Lacility.  Each  has  subcategories  and  descriptive 
values  that  are  capable  of  defining  unique,  individual  entities.  Using  these  descriptive 
values  plus  the  series  of  standard  (or  unique)  relationships  defined  among  the  elements 
we  can  describe  a  thorough  “picture”  of  the  battlefield.  The  picture  can  be  shared  among 
ABCS  systems  and,  with  some  work,  the  supporting  simulations  as  well.  As  mentioned 
earlier,  this  is  significant  progress  in  terms  of  sharing  data  and  provides  to  a  great  degree 
for  the  Situational  Awareness  function  of  a  BML. 

The  employment  aspects  within  the  JCDB  are  categorized  as  Situation,  Plan,  Action, 
Location  and  Capability.  Each  of  these  "items"  also  has  sub-"items"  and  possesses 
descriptive  values.  Currently,  however,  these  categories  and  their  relationships  do  not 
provide  sufficient  structure  to  solve  the  “free  text”  issue,  but  they  do  provide  a  point  of 


departure  for  further  development.  A  significant  portion  of  the  BML  project  is  to  extend 
these  areas  and  their  relationships  and  the  JCDB's  categorization  of  the  physical  elements 
of  the  battlefield,  to  solve  the  “free  text”  problem  in  consonance  with  the  four  principles 
specified  above.  To  address  this  disparity  we  specifically  propose  the  following: 

•  Build  in  the  vocabulary  as  contained  in  FM  101-5-1,  Operational  Terms  and 
Graphics  (future  FM  1-02)  and  BML-1  as  data  tables. 

•  Incorporate  the  doctrinal  base  into  the  Joint  Common  Data  Base  (JCDB). 

•  Build  in  the  syntax  and  semantics  defined  by  the  Army  Universal  Task  List 
(AUTL)  (future  FM  3-15),  the  Army  Training  and  Evaluation  Program  (ARTEP) 
Mission  Training  Plans  (MTP)  and  the  other  related  field  manuals.  Doing  this 
allows  specific  items  to  be  aligned  with  echelon  and  type  unit  as  relationships  in 
the  data  tables. 

Building  the  Vocabulary 

BML  vocabulary  derives  from  English  but  a  more  specific  set  of  definitions  exists  for  the 
military.  The  military  definitions  will  be  incorporated  into  the  JCDB  and,  most 
importantly,  will  be  linked  to  the  specific  uses  that  relate  to  other  elements  contained 
within  the  JCDB.  This  may  seem  straightforward  but  consider  that  the  term  “clear”  has 
eight  primary  definitions  and  an  additional  3  sub-definitions  described  in  Joint 
Publication  1-02  and  FM  101-5-1  plus  three  more  “Army-only”  definitions  in  FM  101-5- 
1.  In  each  the  specific  meaning  relates  to  one  or  more  elements,  such  as  a  piece  of 
equipment,  a  unit,  a  terrain  feature,  an  enemy  force  or  a  combination  as  defined  in  the 
physical  elements  of  the  JCDB,  see  Table  1. 

The  specific  meaning  of  a  term  is  dependent  on  a  number  of  other  factors.  In  other  words, 
it  must  be  taken  within  an  overall  context.  Normally  these  other  factors  consist  of  the 
“Who,  What  When,  Where  and  Why.”  To  add  even  more  complexity  to  the  situation, 
actions  usually  involve  multiple  parties,  and  the  true  context  of  the  term  only  becomes 
apparent  when  all  of  these  are  taken  into  consideration.  For  example,  the  “Who”  may 
consist  of  the  element  that  is  ordering  and  directing  the  action;  the  element  that  is 
carrying  out  the  action(s);  or  the  element  that  is  the  recipient  of  the  action.  These 
complex  relationships  and  their  specific  meanings  can  only  be  understood  if  the  BML  has 
robust  yet  precise  syntax  and  semantics.  These  are  codified  in  the  Army’s  doctrine;  the 
AUTL  and  ARTEP-MTPs.  Additionally,  the  organization  and  placement  of  these  items 
within  an  operations  order  also  contribute  to  their  overall  meaning. 

In  addition  to  defining  terms,  FM  101-5-1  also  defines  graphics  and  symbols  related  to 
the  terms  and  their  definitions.  In  fact  an  entire  operations  order  can  be  created  in 
graphical  form  using  the  BML.  The  functional  BML  will  include  this  and  represent  these 
meanings  and  relationships  appropriately. 

Incorporating  Doctrine 

To  fully  understand  the  need  to  incorporate  Doctrine  into  the  BML  it  is  important  to 
understand  first  what  Army  Doctrine  is  ...  and  is  not.  First  of  all  “Army  doctrine  is 


Definitions  of  the  Term  “Clear”  from  FM  101-5-1 

Joint  Definitions  also  coni 

tained  in  JP  1-02 

Action 

To  Whom/What 

With  Respect  To 

Why 

1 . )  Approve/ Authorize 

a.)  A  person  or  group  of 
people 

Action,  duties, 
movements,  etc. 

Access  to 

b.)  An  object  or  group  of 
objects 

Quality,  quantity, 
disposition,  purpose, 
etc. 

Status  of 

c.)  A  request 

Correctness,  validity, 
etc. 

Execution  of 

2.)  Approve/grant 
authorization 

One  or  more  aircraft 

Flight,  instrument 
flight,  ground 
operations,  etc. 

Take  off,  land,  etc. 

3.)  Grant 

A  person 

A  security  clearance 

Access  to  info 

4.)  Fly 

An  Aircraft 

An  obstacle 

To  avoid  contact 

5.)  Pass 

A  designated  point 

One  or  more  vehicles 

Monitor  movement 

6.)  Operate 

a.)  A  gun 

Ammunition 

Unload  or  confirm 
empty 

b.)  a  Gun 

Stoppages 

Free 

7.)  Clear/free 

An  engine 

Carbon 

Maintenance  of 

8.)  Clear/remove 

Enemy  aircraft 

Designated  airspace 

Achieve  air- 
superiority  or  control 

Army  Specific  Definitions 

1 . )  Remove 

(Note:  this  is  a  tactical  task) 

Enemy  forces/organized 
resistance 

An  assigned  zone,  area 
or  location 

Preclude  interference 
with  friendly 
operations 

2.)  Eliminate 

Transmissions 

A  tactical  radio 
network 

Allow  higher 

precedence 

transmissions 

3.)  Total  elimination  or 
neutralization 

An  obstacle 

Follow  on  engineers 

Provide  mobility  and 
protection 

Note:  This  is  an  abridged  version  of  the  definitions  intended  to  provide  an  insight  into  the  broad  range  and 
scope  of  individual  terms.  Please  see  the  source  document  for  the  full  definition  of  the  term  “Clear”. 

Table  1.  Definitions  Of  The  Term  “Clear” 

authoritative  but  not  prescriptive.”  [4]  Furthermore,  “Doctrine  touches  all  aspects  of  the 
Army.  It  facilitates  communication  among  soldiers  no  matter  where  they  serve, 
contributes  to  a  shared  professional  culture,  and  serves  as  the  basis  for  curricula  in  the 
Army  Education  System.  Army  doctrine  provides  a  common  language  and  a  common 
understanding  of  how  Army  forces  conduct  operations.  It  is  rooted  in  time-tested 
principles  but  is  forward-looking  and  adaptable  to  changing  technologies,  threats,  and 
missions.  Army  doctrine  is  detailed  enough  to  guide  operations,  yet  flexible  enough  to 
allow  commanders  to  exercise  initiative  when  dealing  with  specific  tactical  and 
operational  situations.  To  be  useful,  doctrine  must  be  well  known  and  commonly 
understood.”  [5] 

At  its  highest  levels  Army  Doctrine  is  rather  philosophical  and  as  such  sets  a  generalized 
tone  for  the  language,  e.g.  offensive  operations  constitute  the  decisive  operations  and  the 
Army  is  offensively  oriented.  Additionally,  it  sets  the  high-level  definitions  for  certain 


terms  such  as  those  that  describe  the  types  of  operations  that  the  Army  will  conduct 
(Offensive,  Defensive,  Stability  and  Support),  the  types  of  command  relationships  that 
can  exist  between  units,  forces,  Services  and  nations,  etc.  From  this  point  on,  Army 
doctrine  devolves  down  the  echelons  and  organizations  that  constitute  the  Army  field 
forces  (those  that  are  organized  to  perform  Combat,  Combat  Support  or  Combat  Service 
Support  operations.)  Moving  from  higher  echelons  to  lower,  the  units  themselves  become 
more  specialized  and  differentiated.  Consequently,  at  each  successively  lower  level  the 
doctrinal  characteristics  while  reflecting  the  aspects  of  the  higher  levels,  become  more 
specific  and  detailed  in  their  definitions  of  terms  and  descriptions  of  actions.  As  this 
occurs  the  terms  of  the  “language”  become  related  to  these  particular  types  of  units,  their 
unique  missions  and  individual  equipment  and  capabilities.  If  we  extract  these 
relationships  from  the  lexicon  of  doctrinal  terms  and  enumerate  them  in  the  BML 
specification,  then  we  can  produce  terms  that  have  unambiguous  meaning  and  are  set  in 
operationally  specific  context.  For  instance,  if  the  term  “clear”  is  used  in  an  operations 
order  where  the  performer  of  that  action  is  a  follow  on  Engineer  unit  and  is  associated 
with  a  given  obstacle,  the  intent  is  obvious.  On  the  other  hand,  if  the  same  term  “clear”  is 
used  in  conjunction  with  a  heavy  maneuver  company  team  and  associated  with  an 
objective  (hill  1234),  the  intent  is  also  evident,  yet  significantly  different  from  the 
engineer  mission  context. 

A  critical  aspect  of  developing  BML  is  not  simply  to  specify  the  components  and 
relationships  that  provide  the  context  of  the  language,  but  to  embed  them,  and 
dynamically  link  BML  to  the  Training  and  Doctrine  Command’s  organizations  who 
develop  and  maintain  doctrine.  As  with  any  modem  language  that  is  in  widespread  use 
BML  must  reflect  the  latest  concepts,  capabilities  and  representations  of  the  objects  and 
domain  that  it  represents.  Within  the  world  of  Military  Affairs,  it  is  said  that  the  only 
constant  is  change  itself,  and  the  language  itself  must  be  fully  capable  of  representing  the 
current  status  of  the  domain,  if  it  is  to  be  useful  and  meet  the  conditions  of  Doctrine,  as 
described  above.  In  particular,  as  the  Army  “Transforms”  and  achieves  the  structure  and 
capabilities  of  the  Objective  Lorce  there  will  be  much  adaptation  of  doctrine,  tactics, 
techniques  and  procedures.  While  the  higher-level  “philosophical”  aspects  of  doctrine 
may  remain  stable,  the  lower-level,  more  specific  aspects  can  be  expected  to  change 
rapidly  and  often.  A  well-designed  BML  accommodates  such  change,  and  adds  to 
doctrine  distribution  and  understanding  throughout  the  force. 

Describing  the  devolution  of  Doctrine  from  higher  to  lower,  and  from  the  philosophical 
to  the  specific,  depicts  how  the  military  conducts  operations.  The  missions  originate  at 
the  highest  levels  but  are  executed  at  the  lowest  levels.  In  a  large-scale  operation,  such  as 
Desert  Storm,  the  overall  mission  and  orders  originate  with  the  National  Command 
Authority  and  pass  to  the  Theater  Commander,  the  Land  Component  Commander  (if  one 
is  designated)  and  on  to  the  Lield  Army.  Lrom  the  Lield  Army  orders  proceed  to  the 
multiple  Corps,  subordinate  Divisions,  and  on  to  the  Brigades,  Battalions,  down  to  the 
Companies  and  Platoons  where  the  actual  operations  are  executed.  As  the  orders  cascade 
from  higher  to  lower  they  invoke  the  diverse  units’  specialties.  While  all  Corps  level 
organizations  are  very  similar  in  structure  and  function,  the  difference  in  composition  and 
function  at  the  platoon  level  is  extreme.  These  may  range  from  airborne  and  armored 


combat  forces  through  military  intelligence  and  communications-electronics  combat 
support  elements  to  laundry  and  mortuary  affairs  combat  service  support  platoons,  all  of 
which  derive  their  specific  missions  and  details  from  the  one  original  Corps  order. 
Decomposing  complex  high  level  missions  into  discrete,  executable  sets  of  action  is  one 
of  the  primary  functions  of  operations  orders.  BML  must  enable  and  clearly  communicate 
this  function.  As  an  example,  one  Corps  level  order  will  generate  a  minimum  of  1,163 
additional  subordinate  orders  (see  Table  2).  BML  has  to  clearly  express  the 
decomposition  of  missions  and  units  with  enough  precision  to  cause  correct  behaviors  in 
live  units,  and  supporting  simulations  or,  in  the  future,  robotic  forces. 


Orders  Cascading  From  One  Corps  ( 

Trder 

Corps 

Order 

Div 

Level 

Bde 

Level 

Bn 

Level 

Co 

Level 

Total 

Orders 

1 

5 

48 

193 

917 

1164 

Table  2.  Cascading  of  Orders 
Building  the  Syntax  and  Semantics 

As  discussed  above,  the  doctrinal  base  provides  the  philosophical  underpinning  for  the 
BML,  as  well  as  a  significant  amount  of  the  detail  necessary  to  achieve  the  stated 
objectives  of  the  language.  As  it  stands,  however,  the  base  needs  to  tie  directly  to  the 
AUTL  and  ARTEP-MTPs  to  be  clear,  concise  and  explicit.  The  AUTL  is  developed  in 
conjunction  with  the  Universal  Joint  Task  List  (UJTL)  and  attaches  a  number  to  various 
functions,  missions,  activities,  and  tasks  that  the  Army,  as  a  Service,  can  perform.  The 
tasks  are  then  supported  by  the  ARTEP-MTPs,  which  describe  the  tasks  in  detail  along 
with  the  conditions  and  standards  for  a  given  type  unit  at  a  given  echelon.  These  in  turn 
decompose  all  the  way  town  through  the  platoon,  squad  and  team  level  to  individual 
soldiers,  identified  by  Military  Occupational  Specialty  (MOS)  and  skill  level.  When 
these  tasks  are  associated  with  the  specific  vocabulary  and  unit  data  contained  in  the 
(objective)  JCDB  it  provides  us  with  the  context  required  to  give  meaning  to  the 
particular  use  of  the  terms.  BML  now  has  a  vocabulary  as  well  as  the  required  syntax  and 
semantics. 

Pulling  It  All  Together 

The  preceding  sections  have  described,  in  detail,  all  of  the  elements  that  are  necessary  to 
communicate  clear  and  unambiguous  mission  orders  from  a  human,  supported  by  an 
automated  C2  system,  to  a  subordinate.  This  information  could  be  directed  to  an 
experienced  or  novice  human  subordinate,  a  simple  or  cognitive  agent  simulation  or  a 
future  robotic  FCS  component.  What  remains  is  to  detail  the  specific  relationships 
among  these  elements  and  present  a  common  structure  or  format  to  convey  them. 


The  standard  format  can  be  as  simple  as  a  matrix  assigning  the  Who,  What,  When,  Where 
and  Why  (the  5  Ws)  for  each  subordinate  element  that  is  receiving  a  mission  as  well  as 


the  information  needed  to  coordinate  activities.  Within  the  JCDB  the  ORGANIZATION 
table  provides  the  “Who.”  Its  relationship  to  the  ORGANIZATION-TYPE  table 
associates  the  ORGANIZATION-TYPE  function  and  echelon  codes  to  specific 
organizations.  The  “What”  is  provided  through  the  TASK  table.  TASKS,  a  directed 
activity,  and  EVENTS,  a  significant  occurrence,  are  categories  of  ACTIONS,  an  activity. 
The  ORGANIZATION-TASK  table  provides  the  association  of  tasks  to  specific 
organizations  based  on  the  organization’s  function  and  echelon.  Attributes  of  the  TASK 
table  provide  the  “When”  and  the  “Why.”  The  ACTION-LOCATION  table  provides  the 
“Where.”  Numerous  other  tables  exist  within  the  JCDB  that  contain  enumerations  that 
portray  information  required  to  coordinate  activities  such  as  the  WEAPONS-CONTROL- 
CODE  table.  This  subset  of  JCDB  tables  reflects  a  capability  within  the  JCDB  to 
establish  the  data  and  relationships  required  for  BML  implementation 

Presenting  this  using  the  concepts  and  notations  of  Set  Theory  we  see  that  BML  can  take 
the  attributes  (Tasks,  Units,  etc)  for  all  of  the  forces  within  a  tactical  organization  as  they 
would  reside  within  a  modified  and  expanded  JCDB  and  can  create  a  superset  and 
appropriate  subsets  of  the  5  Ws  that  are  required  to  provide  for  the  cascading  operations 
orders.  This  is  depicted  below: 

What_Cd  is  the  set  of  all  possible  tasks  that  can  be  assigned  to  military  forces  as 
defined  by  doctrinal  manuals.  A  task,  T,  may  be  an  operation  as  defined  by  the 
UJTL  (attack,  defend,  etc.),  a  tactical  task  as  defined  by  FM  101-5-1  (secure, 
clear,  seize,  etc.),  or  an  ARTEP-MTP  task  (conduct  tactical  movement,  conduct 
tactical  road  march,  occupy  an  assembly  area,  etc.). 

What_Cd=  {Ti,T2,  ....Ti}. 

What_Cdunit-tyPe_echeion  is  the  set  of  all  possible  tasks  that  can  be  assigned  to  a  Unit 
of  a  specific  Unit-Type  and  Echelon  as  defined  by  unit-type  and  echelon  specific 
doctrinal  manuals.  What_Cdunit-tyPe_echeion  =  { Tui,  Tu2,  ...TUj},  where  j  is  the  total 
number  of  applicable  tasks  for  echelon  u  and  { Tu i ,  Tu2,  . . . Tuj }  is  a  subset  of  { Ti , 
T2,  ....Tj}  (where  Tui  is  identical  to  one  of  the  tasks  in  { Ti,  T2,  ....T;}). 

As  shown  below  a  task  (Ti)  might  be  common  to  multiple  Unit-Types  and 
Echelons.  For  example  the  task  attack  might  be  common  to  a  Tank/Mech  brigade 
and  battalion  as  well  as  to  a  field  artillery  battalion  and  an  Air  Force  F-15 
Squadron.  Other  tasks  will  be  unique  to  a  specific  unit-type  and  echelon. 

What_CdTank/Mech„BDE  =  {Tl,  T5,  Ts,  T19,  T24,  T30} 

What_CdTank/Mech_BN  =  {Tl,  T5,  Tg,  T32,  T40,  T41  } 

What_CdpA_BN  =  {Ti,  T5,  T50,  T51,  Ts2,  T53} 

What_Cdpi5_sQ  =  {Ti,  T5,  T100,  T101,  T102,  T 103 } 

Unit  has  properties  of  Unit-Type  and  Echelon:  Unitunit-TyPe_Echeion  • 
UnitUnit.TyPe_Echeion  is  associated  with  What_CdUnit  -type_echelon  • 


Why_Cd  is  the  set  of  all  possible  purposes  for  conducting  the  tasks  that  are 
elements  of  What_CD.  The  purposes,  P,  have  been  identified  in  the  same 
doctrinal  manuals  used  to  identify  the  tasks,  T.  The  terms  selected  convey  a 
reason  for  conducting  a  task  and  in  many  cases  the  definition  of  the  term  defines 
an  endstate  condition. 


Why_Cd=  {Pi,P2,  ....Pn}. 

For  any  given  What_Cd  element,  Tx,  where  l<=x<=  i;  there  is  a  corresponding 
subset  of  Why_Cd  elements  associated  with  it.  Why_Cd(Tx)  =  {Pxi,  Px2,  ... 
SP Xmj,  where  m  is  the  total  number  of  applicable  purposes  for  Task  x  and  { Pxi, 
P x2,  ...  SPxm}is  a  subset  of  {Pi,  P2,  ....P„}  and  Pxi  is  identical  to  one  of  the 
purposes  in  {Pi,  P2,  ....Pn}. 


Therefore,  a  mission  or  tasking  statement  that  is  defined  by  the  5  Ws  (Who,  What, 
When,  Where  and  Why)  is  structured  to  a  finite  set  of  possibilities  by  these  set 
associations.  Given  a  Who  =  Unitunit-TyPe_Echeion  (1  BN  40  AR  is  the  name  of  a  unit 
where  Unit-type  =  Tank/Mech  and  Echelon  =  battalion.),  which  is  associated  to 
What_CdUnit-type_echeion;  then  once  a  task,  Tx  is  selected  this  is  associated  to 
Why_Cd(Tx)  allowing  us  to  now  select  a  purpose,  P,  associated  with  why  we 
want  to  do  Tx  for  this  specific  instance. 


Who 

What 

What  Cd 

(T) 

When 

Control  Parameter 

(DTG/Event) 

Where 

Control  Parameter 

(CM/LatLong) 

Why 

Why  Cd 
(P) 

1  BN  40  AR 

ATTACKS 

AT  D  Day,  H-Hour 

CM  ZONE 

SECURE  OBJ  DOG 

Note:  DTG  =  Date-Time  Group,  CM  =  control  measure,  LatLong  =  Latitude/Longitude 

Table  3.  Example  of  the  5  W’s. 


The  Future 

Current  requirements  and  evolving  operational  concepts  call  for  a  wide  variety  of 
advanced  capabilities  to  be  embedded  in  future  C4I  systems.  Among  these  will  be  Course 
of  Action  (COA)  development  and  analysis  tools,  the  capability  to  perform  virtual 
mission  rehearsals  and  the  ability  to  command  and  control  FCS  robotic  entities.  In  many 
instances  such  as  COA  analysis  and  virtual  mission  rehearsal,  a  logical  method  is  to  use 
either  linked  or  embedded  simulations  to  rapidly  execute  the  considered  or  selected  COA. 
This  will  enable  the  commander  and  his/her  staff  to  rapidly  visualize  various  outcomes  of 
each  COA  and  make  adjustments  in  a  rapid  and  responsive  manner.  The  precursor  for 
this  capability  occurred  during  operation  Desert  Shield/Desert  Storm  when  both  the  VII 
Corps  and  XVIII  Airborne  Corps  utilized  the  Army’s  Battle  Command  Training  Program 
and  its  supporting  CBS  simulation  to  conduct  virtual  rehearsals  of  their  operational  plans. 
At  the  time  this  required  the  use  of  couriers  to  convey  the  plans  and  results  between  the 
theater  of  operations  and  the  supporting  simulation  center  at  Ft.  Leavenworth,  KS  for  the 
XVIII  ABC  and  the  deployment  of  a  large-scale  simulation  support  group  to  the  theater 


for  the  VII  Corps.  While  the  results  of  this  effort  were  impressive  the  time  and  resources 
required  make  this  current  capability  incompatible  with  the  tenets  of  Army  Vision  XXI 
and  the  Objective  Force  capabilities.  In  these  cases,  as  in  normal  operational  training,  a 
well- structured,  user  friendly  BML  will  be  critical  to  achieving  this  capability.  Likewise, 
when  directing  future  FCS  robotic  entities  a  commander  can  expect  them  to  have  some 
level  of  artificial  intelligence,  or  at  least  expertise,  but  they  will  lack  the  ability  of  a  well- 
trained  human  to  parse,  analyze  and  understand  free  text  directives.  Rather  than  develop  a 
separate,  additional  capability  to  communicate  with  these  entities  BML  can  accomplish 
this  task  without  requiring  that  commanders  develop  yet  another  unique  yet  narrowly 
focused  skill  set. 

Conclusion 

Current  capabilities  to  link  Tactical  C4I  systems  to  simulations  in  support  of  battle 
focused  training  are  limited.  In  most  cases  the  actual  linkage  occurs  through  support 
personnel  acting  as  workstation  controllers.  While  this  method  of  operation  is  effective  in 
supporting  upper  echelon  battle  command  training  it  is  extremely  resource  intensive  in 
terms  of  both  manpower  and  time  consumption.  Additionally,  it  provides  little  realistic 
concurrent  training  on  the  use  of  organic  C4I  systems  and  in  some  cases  actually  provides 
negative  training  due  to  the  lack  of  stimulation  and  lifelike  loading  of  these  systems.  The 
development  of  an  operationally  focused  BML  will  significantly  eliminate  these 
problems  and  will  act  as  a  catalyst  to  stimulate  multi-echelon  simulation  supported 
operational  training  with  organic  C4I  systems.  Also,  an  operationally  focused  BML  that 
is  embedded  in  the  C4I  systems  can  contribute  significantly  to  the  production, 
dissemination  and  “consumption”  of  automated  operations  orders.  Both  of  these 
capabilities  contribute  significantly  to  achieving  the  Objective  Force  capabilities 
envisioned  in  the  Army  Transformation  Plan. 
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